Data Access with Windows Authentication

One of the ways users can connect to data sources is via Windows Authentication. This type of authentication utilizes the user's credentials - -typically captured in a Kerberos token -to connect and authenticate access to a given data source. The process is often used in big organizations that have centralized security and are using one framework to secure all data assets.

NOTE:

  • Pyramid currently only supports Windows Authentication for MS SQL Server and SAP Logon Tickets for BW. Other data stacks may be added in due course.
  • Windows Authentication is only available when Active Directory is used as the authentication provider for the platform
  • Connections to MS Analysis Services (OLAP or Tabular) DO NOT use this technique. Instead 'effective user tokens' are employed, which achieve the same outcome.

Authentication Options for MS SQL Server

When creating a data source in Pyramid and completing the setup 'card', administrators can elect which type of authentication model to use:

  • SQL Authentication: this is the default, simple model utilizing the user name and password provided by the admin. This is the only option available if Active Directory is NOT used.
  • Windows Authentication (Global): this option will use the global account as the mechanism to authenticate to the data source.
  • Windows Authentication (Service Account): this option will use the account that is running the Pyramid services. Using this option can be very complex, as it requires manually converting all Pyramid services to run under a domain account. Apart from this required change, there are other complexities that might arise with Kerberos (see the Kerberos Guide).
  • Windows Authentication (Alternative Account): similar to the global account, the alternative credentials will be used to authenticate to the data source.
  • Windows Authentication (End User Account): Pyramid will use the credentials of the end-user connecting the application to authenticate to the data source. This is the most used approach but also comes with certain complexities described below.

Enabling End User Windows Authentication

Depending on the method for website authentication, end-user authentication may require extra configurations.

  • If the user logged in via Basic or Forms authentication in the web site, the configurations required are minimal - and simply require admins to ensure the user's login is provided access to the data stack by setting them up as an account on SQL Server itself.
  • If the user logged in via Windows Authentication in the web site, the configurations required are somewhat more complex:
    • Admins need to ensure the user's login is provided access to the data stack by setting them up as an account on SQL Server itself.
    • Kerberos delegation needs to be enabled by admins on the Active Directory for the servers and the Pyramid services. A separate guide for this process can be found here.
    • Ensure that the "Delegate Kerberos" switch is enabled in extended security.